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ABSTRACT 


The U.S. Navy is developing through-water acoustic communications capability 
for undersea, distributed systems. These wireless communication links form a wide-area 
network of fixed nodes consistent with future autonomous sensors on the seafloor. 
Mobile nodes may operate in the domain of the grid using the fixed nodes as both 
navigation reference points and communication access points. This thesis evaluates the 
experimental performance of such networked communications between an undersea 
vehicle and a ship. Physical-layer considerations include refraction, wind-induced 
ambient noise, and vehicle aspect angle. 
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The ATM-885 telesonar modem is designed for use at depths up to 2000 
meters. It is a self-contained, internally or externally powered modem with 
an integral transducer. It is capable of transmission rates from 150 bps to 
15360 bps and can receive at rates from 150 bps to 2400 bps. It utilizes 
MFSK modulation. Channel-tolerance features include data redundancy, 

Vi-rate convolutional coding, and multipath guard period selection [2].3 

This originally proposed Seaweb network was a wide-area grid. The 4 
racom buoys on the deepest contour would provide links to surface vessels 
in the deeper water, while the fifth racom provided a shore connection. 
Depending on mission requirements, Seaweb is able to flex and scale into 
any architecture provided enough nodes are available to support the 

acoustics of the through-water communications medium [2].4 

The planned Seaweb operational network charted in the left figure consists 
of telesonar repeater nodes and racom buoys displayed on the right. The 
grid in its entirety would have been deployed and tested prior to 
commencing the exercise had weather permitted [2]. Nodes indicated in 
the lower left corner of the chart were to be reserved as spares for use 
during an intended 3-day checkout of the grid. Because of foul weather, 
the 3 days of checkout were lost, and all spares were deployed as seen in 

later chapters.5 

The telesonar repeater nodes were deployed from the deck of the second 
ship. It is possible to rig them to be deployed off of a small RHIB, rigid- 
hull inflatable boat. The deployed assembly rises just 5 meters above the 
seafloor and is then recovered by remotely commanding the acoustic 
release. The modem itself is suspended roughly 3 meters above the 
seafloor. The burn wire within the release corrodes and within five 
minutes, the attachment separates from the expendable weight and the 
node floats to the sea surface to be recovered by a RHIB. The telesonar 
modems operate at acoustic frequencies 9-14 kHz. The acoustic release 

transmissions occur at 33 kHz [2].6 

The Seaweb 2004 racom buoy is a low-drag small-cross-section buoy 
tailored for survivability in strong ocean currents. The solar panel provides 
energy during daylight in order to conserve battery energy. A 
microprocessor processes onboard sensor and GPS inputs and controls and 
buffers connections between the telesonar. Iridium, and Free Wave 
modems. The transducer is situated approximately 50 meters down the 
mooring cable to maximize use of the downward refracting channel 

characteristics [3].7 

The wind speed and wave height were measured on a daily basis. These 
phenomena largely determined the ambient noise level within the 








communications channel. Improved Seaweb performance as the 

experiment progressed is partly attributed to decreasing noise levels [2].13 

Figure 7. Weather conditions greatly impact Seaweb performance. The 9-14 kHz 
band is impaired by ambient noise from wind-dependent noise, as shown 
by historically derived noise spectra [12].13 


Figure 8. Historical sound-speed profile for the experiment site indicates a 50-meter 

deep surface mixed layer overlying a strong thermocline [6]. These are 
typical characteristics of continental shelf ocean waters in temperate 


zones.15 

Figure 9. For an acoustic transmitter 3 meters above the seafloor at range 0, a fan of 
223 rays with launch angles between 0° and -11.1° are numerically traced 
through a 255-m deep stratified medium modeled after the historical 

sound-speed profile of Figure 8. [6].15 

Figure 10. Sound-speed profiles measured during the experiment in the area serviced 

by the Seaweb 2004 network show considerable variability. [6].17 

Figure 11. Selected sound-speed profiles showing variation of depth of mixed layer 
and thermocline and localized presence of bottom layer. Locations refer to 

Seaweb node addresses charted on Figure 3.18 

Figure 12. The sound-speed profile measured in the center of the grid near Node R17 
is the basis for the above ray traces. There are 231 beams with launch 
angles between 0° and -13°. A 255-m depth is modeled for comparison 

with Figure 9. [6].18 

Figure 13. Seaweb underwater network is an implementation of the physical, link and 
network layers of the OSI model [7, 8]. The upper three layers are 
mission/application specific, and are normally implemented by the 

Seaweb clients.19 

Figure 14. Seaweb link-layer handshake protocol for data transfer involves Node A 
initiating a request-to-send (RTS) utility packet. So addressed. Node B 
awakens and demodulates the RTS. Node B responds to A with a clear-to- 
send (CTS) utility packet [2, 8].21 


Figure 15. Selective automatic repeat request (SRQ) is a link-layer mechanism for 
reliable transport of large data files between neighboring nodes even when 
the physical layer suffers high bit-error rate. Purple arrows depict Seaweb 
utility packets including RTS, CTS, MAC header (HDR), and SRQ. Red 

arrows are Data subpackets [2, 8].22 

Figure 16. The initial deployed Seaweb operational grid included 2 racom gateway 
buoys and 39 telesonar repeater nodes. The gateway buoys are equipped 
with FreeWave line-of-sight radio links. The ship hosted the Seaweb 
command center, including the Seaweb server with FreeWave interface 

[2].24 

Figure 17. The communications protocol was such that the undersea vehicle would 
initiate all communications. The message flows through the grid, 
ultimately reaching the destination node, i.e., the gateway buoy. The ship 
would reply with a response message delivered through the grid. Then the 
undersea vehicle would send a return receipt to the ship through the grid. 
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Figure 18. 


Figure 19. 


Figure 20. 


Figure 21. 


Figure 22. 


Figure 23. 


Figure 24. 


The Seaweb network layer routes the data packet through the grid based 

on the destination address and the routing tables [2].26 

The Seaweb pilot network was a subset of the proposed operational 
network. It consisted of 7 repeater nodes at positions Rll, R12, R13, R14, 
R15, R16, and R17 and 1 racom gateway buoy at position Gl. The circles 
plotted here show conservative communications range estimates for each 
node—note the shorter range allowed for Gl where the telesonar 
transducer is less than 50 meters below the sea surface and therefore 
subject to shorter direct-path ranges to seafloor stations. The testing of the 
pilot grid by the ship moored at station “RVl” and measurements of the 
prevailing environmental conditions by the second ship reduced risks for 

the final network architecture shown in Figure 19 [2].28 

The actual grid of repeater nodes was deployed eight days prior to the 
beginning of the exercise. Due to inclement weather, end-to-end testing of 
the grid did not take place. Since the three days of planned testing did not 
happen, many troubleshooting types of errors were fixed during the ten 
days of testing. This is one of the reasons for steady performance 

improvements during the course of the experiment [2].30 

Day-by-day changes within the network were accomplished by remote 
polling and control from the ship. These charts demonstrate the impact 
routing can have on the overall performance of the network. They also 
support suggestions that the network can be healed post-major trauma. 
Initial routing relied greatly on the center 300-meter contour column of 
nodes. In hindsight, it is clear that had routing been accomplished sooner 
in the manner accomplished on Day 9 (Figure 21) with the center nodes as 

leaf nodes, Seaweb 2004 performance would have been improved.31 

The network routing on the last day of the experiment. Day 9, is shown on 
the left above in comparison to that which was recovered post-experiment. 
Days 10-11, on the right. The network was severely impacted by trawlers. 

The trawlers were seen within the area on three different occasions. 
Performance was greatly impacted by this major disruption, but reliable 

800 bits/s communications were still maintained.40 

The total amount of messages sent from the undersea vehicle and the ship 
as well as those received onboard the undersea vehicle and ship. One 
hundred and sixty messages were unsuccessfully received onboard the 
ship and fifty messages were not received onboard the undersea vehicle. 

Section C identifies the reasons for these dropped messages.42 

Messaging success from undersea vehicle to ship also tended to increase 
on a daily basis. As the experiment progressed, sensitivity to the issues of 
proximity and aspect of the undersea vehicle relative to the cellular node 

increased messaging success.43 

Messaging success from ship to undersea vehicle increased over the 
course of the experiment. This is attributed to decreasing ambient noise 
levels within the environment, troubleshooting and rerouting of the 
network, and increased operator proficiency.43 
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Figure 25. The ship to undersea vehicle latency is calculated using the timestamps 
entered into the database archives by the Seaweb servers. This is a latency 
that includes the handshaking process between all nodes in the route from 

source to destination.45 

Figure 26. The undersea vehicle to ship latency is calculated using the timestamps 
from the database. The range is determined by using the distance from the 
cellular node the undersea vehicle used to transmit the data packet to the 
ship and back. The distance from the undersea vehicle to the node is 

neglected.46 

Figure 27. Nodal latencies are calculated in the same fashion as those of the ship and 
undersea vehicle. These transmissions were always between fixed 

locations which explain is why they exhibit a more linear fit.46 

Figure 28. The 160 dropped messages not received successfully by the ship are 

attributed to the various factors listed in this chart.48 

Figure 29. The 50 dropped messages not received successfully by the undersea 

vehicle are attributed to the various factors listed in this chart.48 
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I. 


INTRODUCTION 


This thesis examines the ability of an undersea vehicle to communicate through a 
distributed grid deployed on the ocean floor. Half-duplex acoustic links and long 
latencies due to the speed of sound through water are only some of the challenges 
encountered when implementing such mobile connectivity. In 2004, a U.S. Navy Seaweb 
experiment installed a Seaweb grid and achieved networked bidirectional 
communications with an underwater vehicle. This introductory chapter gives a brief 
description of the underwater wireless network and the fixed and mobile nodes used in 
the Seaweb 2004 Experiment. 

A. SEAWEB UNDERWATER WIRELESS NETWORK 

The Seaweb network is intended to provide command, control, communications 
and navigation for autonomous and manned nodes such as fixed sensors and instruments 
on the seabed, undersea vehicles, and surface vehicles operating in arbitrary ocean 
environments for various missions [1]. Seaweb is a distributed grid of interoperable 
telesonar (i.e., te/ecommunications 50und navigation ranging) modems capable of 
supporting networked acoustic communications and node-to-node ranging. To be 
operationally practical, the communication system needs to be reliable, energy efficient, 
deployable, interoperable, flexible, affordable, and secure. The Seaweb grid is scaleable 
and its relatively short links permit physical-layer communications at high enough 
frequencies to support useful bandwidth, small transducers, directivity, deployable 
packaging, low battery power, and inherent transmission security (TRANSEC). Seaweb’s 
architecture is consistent with the Navy mandate for distributed off-board sensors and 
vehicles. 

B. NETWORKING WITH UNDERSEA VEHICLES 

Mobile nodes have unique issues in maintaining connectivity within the Seaweb 
grid. Mobile connectivity is hindered by many factors associated with the telesonar 
physical layer such as the half-duplex links, the long latencies (speed of sound), and the 
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range limitations of the underwater acoustic channel. While transmission loss from 
geometric spreading only depends on propagation range, absorption loss increases with 
both range and frequency, thus limiting the available useful spectral bandwidth. Channel 
behavior is similar to that of a waveguide but shadow zones can exist in the environment 
because of refraction and boundary effects. In addition to these detrimental propagation 
factors, the channel is further impaired by the possibility of high ocean noise levels from 
wind, shipping, and biologies. 

Nevertheless, there has been substantial progress in the ability to operate manned 
and unmanned vehicles at depth while maintaining communications with the terrestrial 
world. While the provision for cellular addressing was incorporated into the Seaweb 2004 
utility packets, the ability of a mobile Seaweb node (e.g. the underwater vehicle) to 
automatically maintain network-layer connectivity has not been fully implemented. This 
was overcome in this experiment with a special-purpose transport-layer protocol 
requiring the undersea vehicle to initiate all communications. As Seaweb advances 
technologically, the ability to maintain network-layer connectivity and communications 
will be further developed. 
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II. SEA WEB COMPONENTS 


Seaweb 2004 was a collaborative experiment involving efforts from SSC San 
Diego, Johns Hopkins University, Naval Postgraduate Sehool, and numerous other 
organizations. The Seaweb grid was installed along the outer eontinental shelf and was 
the largest deployed to date. The network was eomposed of 40 repeater nodes, three 
gateway buoys, two ships, and an undersea vehicle. The goal of Seaweb 2004 was 
bidireetional eommunications with an undersea vehicle operating within the eontext of 
the Seaweb grid. This chapter describes the eomponents of Seaweb and their role in 
supporting the Seaweb 2004 goal. 


A. SEAWEB MODEM 



Figure 1. The ATM-885 telesonar modem is designed for use at depths up to 2000 meters. 

It is a self-eontained, internally or externally powered modem with an integral 
transdueer. It is eapable of transmission rates from 150 bps to 15360 bps and ean 
reeeive at rates from 150 bps to 2400 bps. It utilizes MFSK modulation. Channel- 
tolerance features inelude data redundancy, Vz-rate convolutional coding, and 
multipath guard period seleetion [2]. 

All Seaweb 2004 modems were Benthos Ine. ATM-885 telesonar modems, built 
around the printed cireuit board shown in Figure 1. The modems were upgraded with 
Seaweb Version 14.4 firmware owned and developed by the U.S. Navy. Version 14.4 
retains all previously demonstrated Seaweb functions as discussed in Riee [1], with 
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several upgrades. These upgrades include Doppler processing that permits node-to-node 
range rates in excess of 20 kts, the capacity to address up to 60 nodes, a refined 
Ping/Echo ranging function, and a new networked diagnostic command that remotely 
measures and reports link performance between arbitrarily specified node pairs. 


B. SEA WEB GRID 



Figure 2. This originally proposed Seaweb network was a wide-area grid. The 4 racom 
buoys on the deepest contour would provide links to surface vessels in the deeper 
water, while the fifth racom provided a shore connection. Depending on mission 
requirements, Seaweb is able to flex and scale into any architecture provided 
enough nodes are available to support the acoustics of the through-water 
communications medium [2]. 


Seaweb topology possibilities are limitless due to the ad hoc fashion in which 

nodes can be deployed and networked together. Therefore, dependent upon the mission at 

hand, node deployment stations are chosen to provide the best communications coverage 

possible. The number of available nodes, weather conditions, and the ocean environment 

dictate the area of communications coverage provided by Seaweb. Historical propagation 

predictions, measured sound speed profiles, and ray trace diagrams are used to specify 

the nominal node ranges. The initially proposed Seaweb 2004 topology was a grid 

structure, as charted in Figure 2. As experiment planning progressed, the grid coverage 
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was refined as depicted in Figure 3. Also shown in Figure 3 are components of the 
Seaweb 2004 network during experiment staging. 

To mitigate experiment risk, a pilot grid was deployed and tested just prior to 
experiment commencement. The performance of that pilot grid and analysis of telesonar 
channel conditions guided the final design of the operational Seaweb network. Once the 
full grid was installed, three days were allocated for end-to-end testing that would have 
involved a second ship connecting with each node in the grid for connectivity tests 
between the two ships. Unfortunately, schedule compression due to adverse weather 
precluded the possibility of these 3 days of end-to-end testing. 



Figure 3. The planned Seaweb operational network charted in the left figure consists of 
telesonar repeater nodes and racom buoys displayed on the right. The grid in its 
entirety would have been deployed and tested prior to commencing the exercise 
had weather permitted [2]. Nodes indicated in the lower left corner of the chart 
were to be reserved as spares for use during an intended 3-day checkout of the 
grid. Because of foul weather, the 3 days of checkout were lost, and all spares 
were deployed as seen in later chapters. 
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C. TELESONAR REPEATER NODES 

In Seaweb 2004, all telesonar repeater nodes were hand-deployed from a large 
ship advancing at six knots. Figure 4 depicts the deployment, rigging and posture of the 
repeater node. By virtue of an acoustic release, the repeater nodes are recoverable for 
post-experiment reuse, for mid-experiment servicing, or for mid-experiment 
redeployment to more advantageous locations. The acoustic release connects the 
telesonar modem to the anchor fixing the node to the seafloor. Deployment latitudes and 
longitudes are logged to aid in node recovery and network analysis. 



Subsurface Float 
(24 pounds positive) 


(14 pounds negative) 


Telesonar Modem 


Acoustic Reiease 


Clump Weight 
(60 pounds negative) 




2m 


1m 


.5m 


1m 


.5m 


Figure 4. The telesonar repeater nodes were deployed from the deck of the second ship. It is 
possible to rig them to be deployed off of a small RHIB, rigid-hull inflatable boat. 
The deployed assembly rises just 5 meters above the seafloor and is then 
recovered by remotely commanding the acoustic release. The modem itself is 
suspended roughly 3 meters above the seafloor. The bum wire within the release 
corrodes and within five minutes, the attachment separates from the expendable 
weight and the node floats to the sea surface to be recovered by a RHIB. The 
telesonar modems operate at acoustic frequencies 9-14 kHz. The acoustic release 
transmissions occur at 33 kHz [2]. 
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The stock telesonar modems operate in water depths to 2000 m. Alternative 
pressure housings permit operation to 10,000 m depths. The acoustic releases procured 
for Seaweb 2004 are rated only to 300 meters according to the manufacturer. However, 
during this experiment the repeater nodes were deployed in waters up to 350 meters deep 
without failures. 


D. RACOM BUOYS 



Figure 5. The Seaweb 2004 racom buoy is a low-drag small-cross-section buoy tailored for 
survivability in strong ocean currents. The solar panel provides energy during 
daylight in order to conserve battery energy. A microprocessor processes onboard 
sensor and GPS inputs and controls and buffers connections between the 
telesonar. Iridium, and FreeWave modems. The transducer is situated 
approximately 50 meters down the mooring cable to maximize use of the 
downward refracting channel characteristics [3]. 
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Racom, radio acoustic communication, buoys provide the gateway link between 
the undersea network and the users. The racom buoys used in the Seaweb 2004 
experiment incorporate FreeWave radio technology as well as Iridium satellite 
communication technology. The FreeWave radio provided a line-of-sight radio link 
between the racom buoy and the ship. The Iridium satellite communications link provides 
an alternative to the line-of-sight FreeWave link, but it was not used in Seaweb 2004. 

The new low-drag design of the racom buoy is well suited for operating in strong 
ocean currents. A numerical drag analysis aided in optimizing the scope of the mooring 
line and in determining the anchor requirements. The buoys were anchored to the seafloor 
using a 2.5:1 scope-to-depth ratio on the mooring line. Using the above dimensions, the 
220-meter water depth at the designated racom mooring station produced a 500-m radius 
watch circle around the anchor position [3]. The buoy and mooring design are illustrated 
in Figure 5. 

The racom buoys were deployed from the stern of a ship while underway ahead 
slow into the current. The racom buoy was deployed buoy first, with slow payout of the 
mooring line culminating in release of the anchor at the desired mooring coordinates. 
Because of the severity of sea state and currents at the site, the racom buoys were 
expected to be a vulnerable link in the Seaweb 2004 network. Two racoms were deployed 
prior to beginning the experiment and an additional racom was deployed on the fourth 
day of the experiment for redundancy. Three additional spares were on deck of the 
second ship. [3] 

E. SEAWEB SERVER 

The ship and undersea vehicle each host a Seaweb server. The Seaweb server on 
the ship was designated the Seaweb administrator with power to establish Seaweb 
network-layer routes and specify Seaweb link-layer protocols. The network-layer routes 
are defined by neighbor and routing tables stored on the distributed modems. These tables 
may be remotely modified by the Seaweb administrator. The Seaweb administrator may 
remotely control the physical layer parameters such as bit rate, coding parameters, and 
source level by manipulating register settings in the modems. [4] 
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The server also provides the interface between the Seaweb network and client 
applications. The Seaweb server connects a client end-user to the underwater acoustic 
network through a TCP/IP socket connection. The server queues client outgoing data in a 
message database table and archives the data packet in the modem messages table. Then 
it transmits the packet to the acoustic network through the racom gateway buoy. Many 
types of links between the server and the racom gateway buoy have been previously 
demonstrated. These links include FreeWave line-of-sight packet radio, cellular digital 
packet data (CDPD), Iridium satellite modem, and U.S. Navy submarine sonars. The 
racom gateway node links the Seaweb server to the undersea network through standard 
TCP/IP and RS232 serial protocols. Acoustic network command and control determines 
the destination of the data packet based on the IP address, port number, and 
source/destination id numbers of the acoustic telesonar modems and the client’s Seaweb 
subscription. [4] 

The servers on the ship and undersea vehicle automatically logged the Seaweb 
2004 network activity examined in subsequent chapters of this thesis. The database 
timestamps, archives, and queues all incoming and outgoing data, client information, and 
network statistics. During operations, the server publishes incoming data packets to the 
database for access by terrestrial clients, and queues outgoing data packets to the database 
for delivery into the underwater Seaweb domain. [4] 
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III. EXPERIMENT ENVIRONMENT 


This chapter discusses the environmental variables, including the historical data 
influencing the Seaweb 2004 plan and the measured data observed during conduct of the 
experiment. 

Knowledge of the environment is vital to understanding communications 
performance and to the design of a successful network topology. The environment 
determines the characteristics of the telesonar channel and the communications link 
budget. The channel is determined by the source-to-receiver geometry, transmission loss, 
noise, multipath, and temporal variability. Seaweb 2004 employs signaling technology 
that is immune to expected multipath and temporal variability, as discussed in the next 
chapter. 

A communication link budget derives from the source level of the transmitter, the 
noise level at the receiver and the range-dependent transmission loss [16]. Seaweb 2004 
operations are affected by sound propagation and ambient noise levels for the operating 
band of 9-14 kHz. 

A. CHALLENGES OF THE UNDERWATER ACOUSTIC CHANNEL 

Signals travel much slower in underwater acoustic channels than in conventional 
communication channels. For example, the propagation speed is five orders of magnitude 
slower than that of the radio channel, producing communications latency and potentially 
resulting in a reduction of the overall throughput of the system [11]. 

In addition, the signals suffer significant losses proportional to the transmission 
range. Transmission loss can be attributed to two main factors, attenuation and geometric 
spreading. Attenuation is caused by absorption due to the conversion of acoustic energy 
into heat. It increases with distance and frequency. Geometric spreading refers to the 
diminishing of sound energy density as a result of wavefront expansion. It increases with 
distance at a rate dependent on the channel geometry. Two simple descriptions of 
geometric spreading are spherical, which is seen mainly in deep ocean water, and 
cylindrical, which is seen in shallow water and in ducted channels. [11] 
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The spreading characteristics of deep ocean channels have been explored 
extensively in the literature. Shallow water channels, however, exhibit greater variability 
and are less readily described. Signals experience dispersion from surface and bottom 
interactions and distortion from the combination of multipaths at the receiver [9]. 
Multipath propagation can cause inter-symbol interference (ISI) when the symbol period 
is less than the channel impulse response. Horizontal channels, like those in Seaweb, tend 
to experience rather long multipath spreads. This spread is predominantly a function of 
the water depth and the distance between the transmitter and receiver [11]. Doppler shift 
caused by movement of a communicating modem or by water currents can significantly 
degrade underwater communications. In general, the acoustic modem needs to monitor 
and correct Doppler shifts. 

B. WIND AND SEAS 

Sound propagation is influenced by sea surface conditions, the water medium, and 
bottom characteristics. Without knowledge of all these features it is difficult to predict the 
behavior of sound propagation [11]. The wind speed and wave heights during Seaweb 
2004 were recorded on a daily basis shown in Figure 6. The weather conditions steadily 
improved through the experiment, decreasing the ambient noise level within the channel 
and improving the communications link budget. [5] 

The noise level within a channel directly impacts the communications link budget. 
Most ambient noise can be characterized as having a continuous spectrum and Gaussian 
statistics. It is related to the movement of water including tides, currents, storms, and rain 
as well as seismic and biologic phenomena. Man-made noise is primarily caused by 
machinery noise (pumps, reduction gears, power plants) and shipping activity. Man-made 
noise dominates in areas of especially heavy vessel traffic [11]. In the 9-14 kHz band 
used for telesonar signaling, the ambient noise levels during Seaweb 2004 appeared to be 
associated with wind speed and sea state, consistent with historical noise spectra 
summarized by Figure 7 [12], with elevated levels episodically caused by shipping and 
sonar activity. In addition, multi-user communications by Seaweb itself increases in-band 
noise levels. 
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Figure 6. The wind speed and wave height were measured on a daily basis. These 
phenomena largely determined the ambient noise level within the 
communications channel. Improved Seaweb performance as the experiment 
progressed is partly attributed to decreasing noise levels [2]. 



Figure 7. Weather conditions greatly impact Seaweb performance. The 9-14 kHz band is 
impaired by ambient noise from wind-dependent noise, as shown by historically 
derived noise spectra [12]. 
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C. REFRACTION 

Sound-speed profiles describing sound speed as a function of water depth provide 
information that helps predict telesonar communication ranges. Bathymetry or bottom 
topology at the site also plays an important role. The overall area of coverage served by 
the grid is determined by a combination of the number of nodes used, the distances 
between them, and the maximum communication range of the undersea vehicle. 

When designing the planned Seaweb grid of Figure 3, the historical sound-speed 
profile shown in Figure 8 was used to model sound propagation for the experiment site 
and season. 

The sound-speed gradient of Figure 8 refracts acoustic energy downward away 
from the sea surface. The rays traced in Figure 9 show sound propagation out to the first 
interaction with the seafloor with refraction modeled according to the gradients of the 
historical sound-speed profile. These ray-trace predictions were used to specify the 
nominal node spacing within the grid during experiment planning, assuming conservative 
link-margin estimates requiring direct-path acoustic communications. Such predictions 
afford the network designer an opportunity to deploy the Seaweb nodes in a sparser or 
denser pattern consistent with the tolerance of expected environmental propagation and 
noise conditions. For communications between nodes near the seafloor, downward 
refraction gives favorable propagation by virtue of the long direct-path arcs that are 
supported by the medium. Because performance can be severely degraded by interactions 
of the propagating acoustic signal with a rough sea surface, downward refracting channel 
conditions also favor communications from the undersea vehicle to bottom-mounted 
nodes. In this experiment, where reliable link-layer communications supports the 
objective of network-layer performance analysis, direct-path communications is the 
design criteria for node-to-node link-layer spacing. This is an admittedly conservative 
objective given prior link-layer performance measurements, but the network-layer 
performance is the overriding consideration in this experiment. 
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Figure 8. Historical sound-speed profile for the experiment site indicates a 50-meter deep 
surface mixed layer overlying a strong thermocline [6]. These are typical 
characteristics of continental shelf ocean waters in temperate zones. 
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Figure 9. For an acoustic transmitter 3 meters above the seafloor at range 0, a fan of 223 
rays with launch angles between 0° and -11.1° are numerically traced through a 
255-m deep stratified medium modeled after the historical sound-speed profile of 
Figure 8. [6]. 
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So, ray-trace analysis of the historical sound-speed profile suggests that direct- 
path sound energy would support node-to-node spacing up to 5 km. Direct-path 
propagation is a desirable condition since propagated energy is less subject to distortion 
and dispersion at the rough sea surface boundary, and to entrapment in surface ducts. 
Seaweb mission planners set the nominal distance at 3 km to ensure direct-path energy 
and to mitigate the less predictable noise levels. The 3-km spacing also allows for the 
possibility of individual node failures requiring longer links to heal the network. 
Moreover, a conservative design using 3-km spacing was consistent with the application 
of experimental Seaweb technology to undersea vehicle cellular communications, the 
principal objective of this experiment. It is expected that longer links involving non- 
direct path links are supportable, based on prior experimentation in other environments, 
but these links are not to be counted on given the experimental uncertainties of 
propagation and noise conditions. 

Five days prior to the commencement of the experiment, during Seaweb 
deployment operations, the second ship obtained conductivity-temperature-depth (CTD) 
profiles in the vicinity of the network. Sound-speed profiles derived from these CTD 
profiles are plotted in Figure 10. The shape is generally consistent with the archival 
profile of Figure 8, exhibiting in the upper water column a well-defined mixed layer of 
slightly-increasing sound speed with depth, overlying a thermocline with sound speed 
decreasing strongly with depth. 

However, because of turbulence from major storms, the mixed layer extends to 
about twice the depth shown on historical sound-speed profiles for the area at this time of 
year. Three sound-speed profiles representing geographically separate parts of the 
network are shown for clarity in Figure 11. Differences from the historical profile are in 
the depth of the surface mixed layer and thermocline. The mixed layer depth varies 
between 70 and 125 meters, compared with 50 meters in the historical profile. Some 
profiles show perturbations from a constant gradient in the thermocline and evidence of a 
bottom layer having a gradient distinct from that of the thermocline. 

These measurements provided the acoustic propagation information intended to 
influence the final grid design, had the deployment of the operational grid not been 
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accelerated by the compressed schedule. For the bottom-to-bottom acoustic propagation, 
as seen in Figure 12, the observed sound-speed profiles should support direct-path 
telesonar ranges to about 2400 meters, only half of that predicted from historical 
conditions typical for that time of year. The nominal distance of the nodes had already 
been set at 3000 meters as a conservative spacing choice, and the actual communications 
link budget appeared to be adequate for reliable communications despite the less 
favorable propagation environment. Nevertheless, these weather conditions demonstrate 
the inherent channel dependence of acoustic communications, and the variability that 
affects the propagation medium. 



Sound Speed (m/s) 

Figure 10. Sound-speed profiles measured during the experiment in the area serviced 

by the Seaweb 2004 network show considerable variability. [6] 
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Sound Speed (m/s) 

Figure 11. Selected sound-speed profiles showing variation of depth of mixed layer 

and thermocline and localized presence of bottom layer. Locations refer to 
Seaweb node addresses charted on Figure 3. 
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Figure 12. The sound-speed profile measured in the center of the grid near Node R17 

is the basis for the above ray traces. There are 231 beams with launch angles 
between 0° and -13°. A 255-m depth is modeled for comparison with Figure 9. 
[ 6 ] 
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IV. SEA WEB 2004 COMMUNICATIONS 


The communications architecture utilized in Seaweb 2004 follows the 
International Standards Organization’s Open Systems Interconnection (ISO/OSI) model 
summarized in Figure 13. This reference model is designed to allow for efficient 
communications through seven subtask layers arranged in a hierarchical structure. Each 
layer of the model presents simplified information for further handling at the next higher 
layer. This chapter describes the Seaweb 2004 implemention of the physical and link 
layers. The next chapter examines the Seaweb 2004 network, transport, and session 
layers. 


Application 


Presentation 


Session 


Transport 


Network 


Link 


Physical 


Figure 13. Seaweb underwater network is an implementation of the physical, link and 

network layers of the OSI model [7, 8]. The upper three layers are 
mission/application specific, and are normally implemented by the Seaweb 
clients. 


A. PHYSICAL LAYER 

The physical layer is concerned with transmitting an unstructured bit stream 
through the physical medium. It deals with the mechanical, electrical, functional, and 
procedural characteristics to access the physical medium. 

1. M-ary Frequency Shift Keying (MFSK) 

For Seaweb 2004, the physical layer is based on M-ary Frequency Shift Keying 
(MFSK) modulation of acoustic energy in the 9-14 kHz band. This modulation is favored 
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for acoustic communications for its inherent tolerance of time spread induced by 
multipath and Doppler spread induced by temporal variability. Another advantage of 
MFSK is the ease of implementing receiver algorithms on a fixed-point digital signal 
processing (DSP) chip. The general analytic expression for MFSK modulation is 


S: 


(<) 



for 0< t < T; i=l...M , where the frequency term has M 


discrete values, and the phase term, is an arbitrary constant. The MFSK waveform 
changes frequency combinations from one symbol to the next. These transitions can be 
abrupt because there is no requirement that the phase be continuous. In practice, M is 
usually equal to a power of 2 and all M signals in the set are orthogonal signals, i.e. 

T 

j{t^dt-0\i ^ j. Frequency spacing requirements must be set to ensure 

0 

orthogonality [14]. The Seaweb implementation of MFSK involves the use of 128 tones 
to attain a raw rate of 2400 bits/s. 

2. Forward Error Correction Coding 

Whether dealing with benign or impaired channels, received waveforms can have 
signal components lost due to low signal-to-noise ratios, fading, or interference. To 
mitigate these issues, the introduction of redundancy within a signal by means of coding, 
in effect, distributes the information contained in a single “bit” of data across sub¬ 
channels aiding in reconstruction of the signal [14]. This is called error correction coding. 
Seaweb utilizes forward error correction (FEC), redundant bits that are placed within a 
packet to aid in reconstruction and decoding if the signal is corrupted. 


It is especially desirable within wireless links to employ a form of error correction 
that allows the receiver to correct errors in an incoming transmission on the basis of the 
bits in that transmission. By adding redundancy to the transmitted message, it is possible 
for the receiver to deduce what the original message was, even in the presence of bit 
errors. 


The raw signaling rate of 2400 bits/s is reduced to an effective information bit- 
rate based on the desired degree of coding, redundancy and channel tolerance. Seaweb 
2004 utilized convolutional error correction encoding at a Vi rate. Additional redundancy 
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measures may be invoked to strengthen the signaling at the expense of net throughput. A 
nominal information bit-rate of 800 bits/s was planned with the ability to deerease to 300 
bits/s if prevailing channel conditions warranted. In the actual experiment, the 800 bits/s 
information bit-rate was found to be reliable. 

3. Transmission Optimization 

The Seaweb design is gradually incorporating the ability to continually probe the 
channel, measuring the scattering function, the mathematical expression that describes 
the spreading of signal energy in the time and frequency domains. A handshaking 
process, discussed in section B, then optimizes transmission parameters in a process 
called adaptive modulation. The transmission parameters to be tuned through this process 
include source level, modulation, coding, and bit-rate. [15] 

B. LINK LAYER 

The link layer provides mechanisms for the reliable transfer of information 
through a physical link. Seaweb implements these mechanisms through the use of 
compact 9-byte utility packets. Even when in an energy-conserving sleep state, nodes are 
capable of receiving utility packets that perform functions such as link establishment, 
automatic repeat request, node-to-node ranging, and return receipts. Future link layer 
capabilities will support adaptive modulation [15] and network initialization functions. 
Figures 14 and 15 describe some link-layer mechanisms employed in Seaweb 2004 [2]. 



Node A Node B 


Figure 14. Seaweb link-layer handshake protocol for data transfer involves Node A 

initiating a request-to-send (RTS) utility packet. So addressed. Node B awakens 
and demodulates the RTS. Node B responds to A with a clear-to-send (CTS) 
utility packet [2, 8]. 
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Node A 


Node B 


1. Node A initiates a 
iink-iayer diaiog with 
Node B. 

3. Node A transmits a 
4000-byte Data packet 
using 16 256-byte 
subpackets, each with 
an independent CRC. 


6. Node A retransmits 
the 4 subpackets 
specified by the SRQ 
mask. 


8. Node A retransmits 
the 1 subpacket 
specified by the SRQ. 



2. Node B is prepared to receive a iarge Data 
packet as a resuit of RTS/CTS handshaking. 


4. Node B receives 12 subpackets successfuiiy; 

4 subpackets contained uncorrectabie bit errors. 

5. Node B issues an SRQ utiiity packet, inciuding 
a 16-bit mask specifying the 4 subpackets to be 
retransmitted. 

7. Node B receives 3 of the 4 packets 
successfuiiy (future impiementation of cross-layer 
time-diversity processing will recover 4 of 4). B 
issues an SRQ for the remaining subpacket. 

9. Node B successfully receives and 
processes Data packet. 


Figure 15. Selective automatic repeat request (SRQ) is a link-layer mechanism for 

reliable transport of large data files between neighboring nodes even when the 
physical layer suffers high bit-error rate. Purple arrows depict Seaweb utility 
packets including RTS, CTS, MAC header (HDR), and SRQ. Red arrows are Data 
subpackets [2, 8]. 
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V. SEA WEB 2004 NETWORKING 


The network layer controls the data routing and switching technologies used to 
connect systems. The transport layer involves source-to-destination addressing and 
information assurance mechanisms. Seaweb implements these network and transport 
capabilities on the modem. For Seaweb 2004, a session layer protocol was instituted to 
accommodate unique characteristics of a mobile node operating in a fixed grid. 
Performance metrics include availability, reliability, throughput, transit delay, transit 
jitter, and connection establishment delay. 

A. NETWORK ROUTING 

The network layer determines how messages are routed through the network from 
source node to destination node. As introduced in the previous chapter, Seaweb 
communications involves utility packets and data packets. The utility packets are 9 bytes, 
while Seaweb 2004 data packets may be up to 2 kilobytes. The utility packets of interest 
at the network layer are Receipts (RCPT) and Acknowledgments (ACK). Figure 15 
shows the link layer movement of a data packet from node to node, representing just one 
hop in a network layer route that may have many such hops connecting source to 
destination node. 

Seaweb 2004 did not employ an embedded, dynamic routing algorithm. Instead, 
the Seaweb administrator specified fixed routing by means of data structures maintained 
at each node. These distributed data structures are the Seaweb routing tables and neighbor 
tables. In Seaweb 2004 these tables were managed and manipulated only by the Seaweb 
administrator aboard the ship. 

Routes are derived from a combination of the three routing approaches used in the 
development of internet routing protocols: distance-vector routing, link-state routing, and 
path-vector routing. Distance-vector routing requires that each node exchange 
information with its neighboring nodes. Each node then maintains a table of link costs for 
each directly attached node, and next-hop vectors for each destination node. A link-state 
router determines the link cost on each of its network interfaces, and advertises these 
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settings to all of the nodes within the system. The individual nodes then monitor the link 
costs. With path-vector routing, information is provided about which nodes can be 
reached via a certain node. It does not account for the distance or cost estimate [14]. 

The Seaweb 2004 network required the administrator to estimate all of the above 
parameters and combine them in an ad hoc fashion to determine which routing scheme 
would best support message delivery. Seaweb routing will be automated as the 
technology evolves, and the Seaweb 2004 utility packet formats and network layer data 
structures anticipate that evolution. 



Figure 16. The initial deployed Seaweb operational grid included 2 racom gateway 

buoys and 39 telesonar repeater nodes. The gateway buoys are equipped with 
FreeWave line-of-sight radio links. The ship hosted the Seaweb command center, 
including the Seaweb server with FreeWave interface [2]. 
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During Seaweb 2004, the ship was responsible for monitoring the performance of 
each node and the characteristics of each link, determining when and if the routing tables 
needed to be changed. When each node was deployed it had an initial routing table 
programmed within the modem. The original routing configuration is shown in Figure 16. 

Channel/link characteristics changed throughout the experiment as a result of 
varying noise levels. As seen in Figure 6, during the first five days of the experiment, 
high winds and seas elevated the noise level, and decreased the link budget. Channel/link 
characteristics were also affected by trawling impact, examined in subsequent chapters. 
Nevertheless, a reliable 800 bits/s physical layer was available throughout the 
experiment. 

Upon successfully reaching the destination node, if the return receipt flag is set in 
the data packet header, the transport layer automatically generates a return receipt and 
routes it back to the source node following an efficient and reliable RCPT/ACK link- 
layer mechanism. 

B. MOBILE NODE INTEGRATION 

Extreme channel variability between moving nodes is a major limitation for 
mobile underwater communication systems. In addition to the motion-induced pulse 
compression and dilation of received signals, the channel geometry and multipath 
structure change rapidly, limiting applicability of receivers requiring significant channel 
coherence. The Seaweb 2004 physical layer was relatively immune to these effects, by 
virtue of non-coherently processed MFSK modulation and special measures for Doppler 
tolerance. 

A more serious challenge is the fact that the undersea vehicle in Seaweb 2004 was 
not an omni-directional receiver, unlike the nodes of the fixed grid. The undersea vehicle 
suffers as a receiver when its own hull obstructs arriving sound energy. These outages are 
dependent on its own orientation in relationship to the direction of incoming signal 
propagation. Additionally, the undersea vehicle is a relatively noisy receiver because of 
flow noise, propeller noise, and other mechanical noise. These combined factors make 
the mobile node a disadvantaged receiver compared to the fixed node. 
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C. SESSION PROTOCOL 

The state of the art of Seaweb 2004 mobile connectivity compelled the use of a 
session-layer protocol requiring the undersea vehicle to initiate network-layer dialogs. 
The mobile node would declare the nearest node to be the cellular address, and would 
access the Seaweb route to the destination node via the cellular node. When the ship 
received the initiating message (data packet), it would reply with a response message 
(data packet) via the reciprocal route to the cellular node indicated within the initiating 
message, and the cellular node would directly address the mobile node. Upon receiving 
the response, the Seaweb modem on the undersea vehicle would immediately and 
automatically return a receipt to the ship, again via the cellular address and the fixed 
route. The Seaweb 2004 session-layer protocol is summarized graphically in Figure 17. 




Response message 

^ s ^ 

^ s ^ 

^ s ^ 

^ Initiating message Return receipt 

Undersea Vehicle Undersea Vehicle 




Figure 17. The communications protocol was such that the undersea vehicle would 

initiate all communications. The message flows through the grid, ultimately 
reaching the destination node, i.e., the gateway buoy. The ship would reply with a 
response message delivered through the grid. Then the undersea vehicle would 
send a return receipt to the ship through the grid. The Seaweb network layer 
routes the data packet through the grid based on the destination address and the 
routing tables [2]. 
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VI. SEA WEB 2004 NETWORK GRID 


A. DEPLOYMENT 

The first step in implementing the Seaweb 2004 cellular grid was to perform in¬ 
air networking tests at an ashore facility. These tests occurred many days prior to the pilot 
grid deployment, and exercised message routing through the actual experiment hardware. 
The procedure involves physically arranging nodes adjacent to their neighbor nodes in 
the grid. Test messages are then sent from source to destination via the intended 
communications route through the network. This process enables operators to diagnose 
and fix potential networking and mechanical problems prior to deploying the Seaweb 
nodes in the water. After in-air testing was completed, all acoustic releases were 
assembled and rigged for deployment. Forty-seven telesonar repeater nodes and six 
racom gateway buoys were then loaded aboard the second ship and secured for the 
underway transit to the experiment site on the outer continental shelf. 

Six days prior to the commencement of the experiment, a Seaweb pilot network 
consisting of 7 repeater nodes and 1 racom gateway buoy was deployed as charted in 
Figure 18. Basic ringing out of the grid indicated adequacy of the node-to-node spacing 
and grid design. 

Then, during the afternoon and evening of the same day, the second ship deployed 
an additional 32 repeater nodes and 1 racom buoy, forming the operational grid of 39 
repeater nodes and 2 racom gateway nodes charted in Figure 19. Based on time reports 
collected from the second ship, the average deployment time required per node was just 
20 minutes, including node-to-node transit time [2]. 

Full deployment of the operational grid represented an accelerated evolution 
driven by several constraints, including a compressed schedule, incoming inclement 
weather, and avoidance of interference with other experiment platforms operating in the 
same area. A further impact of the accelerated schedule was the omission of a planned 3 
days of end-to-end network testing between each node and the racom gateway. The 
operational network did not benefit from this pre-experiment checkout process and any 
fine-tuning that might have ensued. 
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Figure 18. The Seaweb pilot network was a subset of the proposed operational 

network. It consisted of 7 repeater nodes at positions Rll, R12, R13, R14, R15, 
R16, and R17 and 1 racom gateway buoy at position Gl. The circles plotted here 
show conservative communications range estimates for each node—note the 
shorter range allowed for Gl where the telesonar transducer is less than 50 meters 
below the sea surface and therefore subject to shorter direct-path ranges to 
seafloor stations. The testing of the pilot grid by the ship moored at station “RVl” 
and measurements of the prevailing environmental conditions by the second ship 
reduced risks for the final network architecture shown in Figure 19 [2]. 


As part of the deployment process, the second ship moored 2 racom gateway 
buoys in the Southwestern portion of the network. The racom buoys require a more 
intensive preparation process, but took only 6-8 minutes to deploy. The moored racom 
buoys handled the high seas, high winds, and strong currents at the experiment site during 
this maiden deployment, however brief. 

After deploying the bed of repeater nodes, it was decided that the second ship 
would recover the two racom gateway buoys. Warnings of inclement weather gave 
concern that the buoys would have been unnecessarily at risk. Sea states were too high 
for use of a RHIB to assist in the buoy recovery, so the ship went it alone. Both buoys 
were retrieved, but major damage incurred by the heavy-handed recovery process 
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rendered them useless for the rest of the experiment. Both moorings were lost, both 
telesonar transducers were lost, both telesonar transducer cables were damaged beyond 
repair, one Iridium antenna was lost, one GPS antenna was damaged, and one FreeWave 
antenna was lost. Visual inspection indicated that the seas had not damaged the buoy 
portion, however [3]. This indicated that the new racom buoys are survivable in six to 
nine foot seas. 

The most serious loss during the racom recovery was the two telesonar transducer 
cables. Although the second ship had four additional new buoys on deck, they only had 
one 50-meter telesonar transducer cable. This was a result of the short contract schedule 
in combination with the relatively long lead-time on the cables. Therefore, a 20-meter 
cable was fabricated by joining two available 10-meter cables. If this had not worked, the 
contingency plan had been to use a telesonar transducer deployed over the side of the 
ship in place of the racom gateway buoy [18]. 

One day prior to commencing experimentation, the second ship deployed two 
racom gateway buoys designated Gib and G2b in the vicinity of the two that were 
recovered previously. To avoid entanglement with remnants of Gla and G2a, the new 
buoy moorings were displaced slightly from the earlier posits. Gib stood approximately 
500 meters east of Gla and G2b approximately 500 meters north of G2a [3, 18]. 

A problem at racom buoy G2b with the telesonar transducer or telesonar transduer 
cable prevented telesonar communications and was identified the same day of 
deployment. It was felt that Racom gateway buoy G2b needed to be recovered and 
serviced. The failure was isolated and confirmed by various means, including testing via 
direct telesonar communications from RV1 using an over-the-side telesonar deck unit. It 
was determined that when daylight and seas permitted, the second ship would execute a 
controlled recovery. All Seaweb repeater nodes were functional with exception of Nodes 
20 and 35. They responded to Seaweb utility packets, but had difficulty with higher bit- 
rate data packets. This was thought to be due to the transducers being occluded by a 
fouled or tangled rigging. For this reason, the Seaweb routing avoided Node 20 for the 
first day of testing. 
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Figure 19. The actual grid of repeater nodes was deployed eight days prior to the 

beginning of the exercise. Due to inclement weather, end-to-end testing of the 
grid did not take place. Since the three days of planned testing did not happen, 
many troubleshooting types of errors were fixed during the ten days of testing. 
This is one of the reasons for steady performance improvements during the course 
of the experiment [2]. 

B. NETWORK REROUTING 

During the post-experiment recovery of the repeaters it was confirmed that the 
central column of the Seaweb grid suffered major trauma by trawling activity. The 
inability to recover 8 of the repeater nodes is largely attributable to the trawling activity, 
with a variety of failure modes described in greater detail in Section C. Despite this 
damage, the Seaweb administrators on the ship incrementally established connectivity 
within the grid. Through remote polling and remote control of the Seaweb network layer, 
administrators healed the network. This significant achievement of the exercise 
anticipates future automatic initialization of ad hoc Seaweb grids, including the 
assimilation of nodes deployed by various platform types over time, including Unmanned 
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Aerial Vehicle (UAV), Unmanned Surface Vehicle (USV), Unmanned Undersea Vehicle 
(UUV), SEAL Delivery Vehicle (SDV), Maritime Patrol Aircraft (MPA), attack 
submarines (SSN), etc. 

Day-to-day changes in the network routing are shown in Figure 20. 



Figure 20. Day-by-day changes within the network were accomplished by remote 

polling and control from the ship. These charts demonstrate the impact routing 
can have on the overall performance of the network. They also support 
suggestions that the network can be healed post-major trauma. Initial routing 
relied greatly on the center 300-meter contour column of nodes. In hindsight, it is 
clear that had routing been accomplished sooner in the manner accomplished on 
Day 9 (Figure 21) with the center nodes as leaf nodes, Seaweb 2004 performance 
would have been improved. 
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1. Day One 

During the first day of operations connectivity with the racom buoy via the 
FreeWave line-of-sight radio link was occasionally lost for long periods of time as the 
ship ventured away from the buoys. A FreeWave range of 4 nmi or less was needed for 
the ship to maintain uninterrupted connectivity since the low-profile racom buoy was 
periodically within a trough with the radio link momentarily occluded by a wave crest. In 
subsequent days, the ship was moored in position just 2 nmi from the racom moorings. At 
this range the ship maintained solid uninterrupted connectivity with the racom buoy. 
Testing of the grid continued throughout day 1. This included adjusting bit-rates from 
300 to 800 bits/s, adjusting routes, and setting power levels. It is important to again note 
that the original schedule allowed for up to 3 days to ring out the grid, in conjunction 
with node servicing support from the second ship. Due to the inclement weather and all 
ships being sent back to port, this end-to-end testing did not happen. 

The second ship had four spare telesonar repeater nodes, four pairs of acoustic 
releases, forty-one weights, and one spare float onboard. Four additional racom buoys, 
one ready for deployment, were on deck. Transducer cables proved to be the limiting 
factor for racom buoy availability. Two of the 50-meter cables were severed during the 
aforementioned recovery and the third was on the inoperative deployed racom. The 
working deployed racom had a makeshift 50-m cable created during the unexpected 
anchorage by splicing a 50-meter deck unit cable onto the stub of one of the severed 
cables. 

There was not a significant amount of rerouting of the network on day one, since 
the network needed to remain available for use by the undersea vehicle. With limited 
Seaweb personnel on the ship, the Seaweb server could not be manned around the clock. 
Seaweb personnel rested during the afternoon and evening hours in order to prepare for 
the day 1 events. Occasionally the communication link between the ship and the racom 
buoy would drop out due to high seas and maneuvering of the ship. These outages 
required reestablishment of the communications session and interrupted Seaweb service. 
Outages usually were on the order of minutes, but in one case was over 30 minutes. 
Without access to the gateway, it was difficult to maintain and monitor all aspects of the 
network. 
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The schedule of events demanded that event 1 commence despite high seas and 
winds that presented unfavorable noise conditions for acoustic communications. During 
the event, the ship bridge reported seas up to 12 feet. The undersea vehicle operated near 
the sea surface which disadvantaged the vehicle as a receiver, primarily because of high 
noise levels, but also because of the deep mixed layer and the aspect-dependent mounted 
transducer. 

The ship could communicate with Nodes 20 and 35 with Seaweb utility packets, 
but not with data packets. Seaweb administrators rerouted network traffic around 20, but 
only partially rerouted around 35. Meanwhile, plans for the deployment of a third racom 
buoy to back up the one functioning racom unit were developed. High seas would prove 
to stall this deployment until day four of experimentation. 

When the grid was deployed the network relied heavily on the left and center 
columns of nodes. Both were routed straight down to the gateway. The right column was 
routed in as leaf nodes. Because of lack of confidence in Node 20, the southernmost 
portion of the grid was rerouted. As well. Nodes 35 and 47 were not yet operating 
properly. Therefore, in hindsight, the northeastern portion of the grid was deemed 
inoperable for the day of operations and testing. 

The first message sent by the undersea vehicle was via Node 42 in the most 
northerly section of the grid. The ship sent a reply, but a return receipt was not received 
at the ship. The undersea vehicle was deemed to be a disadvantaged receiver when 
operating at shallow depths, especially in high seas where ambient noise in the 9-14 kHz 
Seaweb band is dominated by wind and sea-surface turbulence. Compounding this was 
the strong and deep mixed layer. When the undersea vehicle operated at lower depths it 
would experience better communications. Despite adverse conditions, data packets from 
the undersea vehicle were successfully transmitted to the ship via cellular Nodes 42, 24, 
22, 22, 19, 19, 21, 21, 21, and 22, consecutively. All activity was logged and time- 
stamped by the Seaweb server on the ship. 
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2. Day Two 

On Day 2, the network seemed to have been hindered by more than just the 12- 
foot seas and 30-kt Northerly winds. Due to an apparent malfunction within Node 25, the 
majority of the network could not be accessed. At the time, it was unclear what had 
happened to Node 25, other than the fact that it was not operating properly. In retrospect, 
all evidence indicates that Node 25 was lost to trawling on this day. As seen in Figure 20, 
without Node 25, the entire northern portion of the grid was inoperable. In order for 
communications to resume, it was necessary to reroute around 25. As well, the ship’s 
moor had become unstable and the ship was moving within the buoy box causing Free 
Wave radio connectivity issues with the racom gateway buoy. 

During Day 2, messages arriving from the undersea vehicle did not reveal the 
Seaweb cellular address as intended, thus thwarting the intended response messaging in 
the Seaweb 2004 session layer protocol. This cellular address is embedded in the Seaweb 
header utility packet and a simple Seaweb modem firmware change would be required to 
extract it. Had the schedule permitted, end-to-end connectivity testing would have 
revealed this problem before experiment commencement. A workaround involved 
reprogramming the undersea vehicle to explicitly declare the cellular address in the body 
of transmitted messages. The network issues experienced this day allowed only one data 
packet from the undersea vehicle to be transmitted to the ship via cellular Node 22. 

3. Day Three 

Day 3 brought successful bidirectional communications. The ship communicated 
successfully with all deployed nodes in the grid with the exceptions of Nodes 23 and 25. 
Both nodes were thought to have failed, and in fact were probably trawled out. Therefore, 
a plan for replacement was developed. Upon replacement of the repeater nodes, the 
second ship was to deploy an additional racom buoy in the same general area as the 
others as a backup gateway node, and if time permitted, the ship would also use a 
telesonar deck unit for direct interrogation and reprogramming of Nodes 37, 38, 39, 40, 
41, and 42. It is important to note again, that if time and weather had allowed, direct 
interrogation and reprogramming of nodes would have been completed days earlier 
during end-to-end testing. 
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During Day 3 numerous routing and performance issues in the grid that would 
normally have been corrected prior to the exercise were resolved with the aid of the 
second ship. Rerouting was very successful. At the end of Day 3 only four nodes were 
unavailable due to a lingering issue with Node 36. Data packets from the undersea 
vehicle were successfully transmitted to the ship via cellular Nodes 17, 17, 20, 18, 18, 17, 
17, 20, 19, 19, 17, 20, 26, 44, 44, 44, 27, 31, 47, 48, 48, 49, 48, and 48, consecutively. 

4. Day Four 

Finally, on the fourth day of the experiment, mild winds and seas allowed the 
second ship to deploy the additional racom buoy in the vicinity of the other two gateways 
as a backup gateway node. Racom buoy G2b was left in the water because it remained 
functional in terms of the FreeWave link and as a telesonar receiver, and because 
recovering it might have endangered the other nearby racom buoys. The second ship 
attempted to recover Node 23, but actuation of the acoustic release did not result in the 
surfacing of the node. This could have been because of the node depth, or because of the 
trawling of the grid. Due to time constraints, recovery of Node 25 was not attempted. 
Node 55, the replacement for the two nodes, was deployed and successfully assimilated 
into the grid. Two trawling vessels were observed operating within the Seaweb grid 
during Node 55 deployment, further supporting suspicions of trawling down the center 
column of nodes. It is believed that Nodes 23 and 25 were both removed from the grid 
during earlier trawling. 

Communications were further improved by the lower undersea ambient noise 
during day four of testing, but issues with Nodes 32 and 33 prevented traffic flow from 
Nodes 34 and 35 north. Data packets from the undersea vehicle were successfully 
transmitted to the ship via cellular Nodes 45, 26, 28, 24, 20, 44, 24, and 20, 
consecutively. 

5. Day Five 

Day 5 brought the return of high ambient noise levels with increasing winds and 
seas. The ship communicated successfully with all deployed nodes in the grid. Node 55 
deployed on Day 4 was functioning, but with weak performance. On Day 5 no packets 
were sent to it or from it, therefore it was considered out of the network. Because Nodes 
23, 25, and 55 were concentrated in one particular area, an area with somewhat more 
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bathymetric gradient than elsewhere in the grid, it was erroneously hypothesized at the 
time that this telesonar dead zone was a result of seafloor properties. 

Minor maintenance on the grid took place on Day 5, but the northern portion of 
the left and center columns were problematic. Data packets from the undersea vehicle 
were successfully transmitted to the ship via cellular Nodes 19, 28, 43, 24, 24, 43, 43, 55, 
44, and 43, consecutively. 

6. Day Six 

Calmer conditions prevailed on Day 6. Winds were approximately 10-20 kts and 
seas 2 to 4 feet with swells of 6 to 8 feet. The ship was moored just 2 nautical miles from 
the racom buoys and maintained continuous FreeWave connectivity with the deployed 
gateways. Network rerouting was at a minimum and it appeared as if the network was in 
working order, with the exception of the center column on the 300-meter contour. The 
entire left column was functional. Node 55 also appeared to be in working order. Data 
packets from the undersea vehicle were successfully transmitted to the ship via cellular 
Nodes 35, 35, 34, 34, 24, 21, 24, 26, 24, 20, 44 and 43, consecutively. 

7. Day Seven 

The weather provided calm conditions with winds from 10 to 15 kts and seas of 2 
to 4 feet with swells of 4 to 6 feet. Only two minor network changes were made, and the 
center column of nodes still exhibited problems. Although the undersea vehicle operated 
in the domain of the Seaweb grid only briefly this day, data packets were successfully 
transmitted to the ship via cellular Nodes 30, 28, 26, 22, 21, and 24, consecutively. 

8. Day Eight 

By the end of the experiment, the deployed Seaweb grid of 3 racom buoys and 40 
repeaters were fully functional, save for Nodes 23 and 25. The 7 nodes composing the 
original pilot grid (Seaweb Nodes 11-17) had been deployed 16 days and remained 
operational with good battery readings. The remaining nodes forming the rest of the 
operational grid had been deployed 15 days with good battery readings. The ship 
personnel optimized network routing and verified connectivity with the deployed 
modems in the grid. The successful rerouting of the network shows the feasibility and 
importance of future Seaweb networks to heal routing following the loss or addition of 
nodes. On Day 8 data packets from the undersea vehicle were successfully transmitted to 
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the ship via cellular Nodes 24, 21, 21, 19, 19, 21, 22, 26, 28, 30, 34, 32, 30, 26, 26, 44, 
19, 19, 24, 28, 29, 27, 55, 22, 32, 32, and 32, consecutively. 

9. Day Nine 

Interestingly, at the end of the experiment, the network routing was at its most 
optimal. Unfortunately the undersea vehicle did not transmit data packets during Day 9 of 
operations because it was operating elsewhere. After recovery of the grid and finding 
concrete evidence of trawling along the center column, it is obvious that had the network 
incorporated the center column as leaf nodes, the trawling would have had less of an 
impact and less rerouting would have occurred. However, the process followed by the 
remote administrator to reach this state of functionality is highly instructional and led to 
identification of several new commands that were implemented post-experiment. It is 
also justification for the training of additional operators for future experimentation. 


C. RECOVERY 

After the final day of testing, the second ship progressively recovered the Seaweb 
network. Utilizing the GPS locations of all node deployment locations, the second ship 
transited the grid and utilized a deck-box to actuate the acoustic release for recovery. 
Upon recovery, it became even more evident that the grid had been severely impacted by 
trawling. Figure 21 shows the network as routed by the Seaweb administrator in the final 
day of experimentation. Day 9, alongside the actual grid that was recovered. The 
deviations and casualties are significant and suggest that with added diagnostic features, 
Seaweb would be able to self-heal and overcome quite significant damage. 

The following 32 repeaters were successfully recovered: 11, 12, 13, 14, 15, 16, 
17, 18, 19, 20, 22, 24, 26, 28, 29, 30, 32, 34, 36, 38, 39, 40, 41, 42, 43, 44, 46, 47, 48, and 
49. This 80% recovery rate is notable in that it was achieved without support from a 
RHIB, in a strong current, and with several nodes deployed deeper than the specified 
operating depth of the acoustic releases. Node 29 was not found in its original 
deployment position. It was successfully recovered at a location 2.5 km away from its 
deployment station. This dislocation is thought to have occurred due to trawlers working 
the area. Furthermore, it is suspected that most of the unrecoverable nodes were damaged 
by the bottom trawling. 
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Even with the daily reconstruction of the network routes, it is difficult to pinpoint 
on which day and at what time the trawling took place. We know that two trawlers were 
operating within the area of the Seaweb grid throughout recovery operations, Days 11-13. 
The second ship had previously observed two similar trawlers in the same area on Day 3 
of experimentation during the deployment of Node 55. Seven of the eight unrecoverable 
nodes and the one dislocated node were all from the center column of the grid. This 
indicated that trawling was concentrated along the 300-meter contour. This is the same 
area in which the trawler sightings occurred. Failure modes associated with the dislocated 
and unrecoverable nodes were also consistent with contact by trawls. With all of the 
evidence, it appears the major trawling impact occurred on or before Day 2. 

No traces of Nodes 23 or 25 were found, despite ping attempts throughout the 
entire grid area. All 3 independent acoustic systems (telesonar modem and the pair of 
acoustic releases) did not respond. These nodes were problematic from the beginning of 
the exercise and are presumed to have been trawled in the days immediately following 
deployment. 

Node 27 was found 2.0 km 35 IT away from its deployment station. The node was 
located through ranging and trilateration from neighboring nodes using Seaweb 
navigation functions. Although all 3 acoustic systems were responsive, ranging by the 
deck box revealed the location of the releases were 300 meters away from the telesonar 
modem, indicating the release had separated from the modem. Failure of the float to 
surface following successive bum commands to both acoustic releases indicates the float 
had been severed. 

Node 29 was successfully recovered, although it was found 2.5 km 349T away 
from its deployment station. The telesonar modem was undamaged but showed traces of 
red and green paint. This telesonar modem carried sediment indicative of being dragged 
along the bottom. 

Node 31 was found 2.2 km 262T away from its deployment station. All 3 acoustic 
systems were responsive; therefore failure of the node to surface following burn 
commands to both acoustic releases indicates the float had been severed. This node was 
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found to be collocated with Node 33, suggesting these nodes had perhaps been hauled up, 
floats severed, and the modems and releases discarded overboard. 

Node 33 was found 4.7 km 18 IT away from its deployment station. All 3 acoustic 
systems were responsive. It is thought that the sub-surface float was severed from this 
node as well. 

Node 35 was found at its deployment station, however it did not surface. Loss of 
the float would have caused the modem to rest on the seafloor and possibly bury in the 
sediment. A collapsed posture is consistent with the poor acoustic performance of this 
node during the experiment. Node 37 was also found at its deployment station, but did 
not surface. 

Node 45 did not respond through either the telesonar modem or acoustic releases. 
This is the only unrecovered node not belonging to the center column. Therefore, its 
failure is not necessarily attributable to trawling. This node was in water deeper than the 
300-m rating of the acoustic releases, but there is no direct evidence to indicate failure of 
the releases. 
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Figure 21. 



The network routing on the last day of the experiment, Day 9, is shown on 
the left above in comparison to that which was recovered post-experiment, Days 
10-11, on the right. The network was severely impacted by trawlers. The trawlers 
were seen within the area on three different occasions. Performance was greatly 
impacted by this major disruption, but reliable 800 bits/s communications were 
still maintained. 
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VII. SEA WEB 2004 PEREORMANCE 


Seaweb quality of service is limited by low-bandwidth, half-duplex, and high- 
latency telesonar links. Poor propagation conditions and elevated noise levels contribute 
to occasional network outages and corrupted data packets [9]. Seaweb 2004 performance 
is quantified by the overall message throughput, latency of network packets, and the 
contributing factors for the dropped messages. 

A. MESSAGING SUCCESS 

Throughput is defined as the amount of information transmitted through a 
communications link. Factors such as bandwidth, errors, congestion, and the transmission 
medium properties affect the total throughput values. For this analysis we discuss 
throughput in terms of overall messaging success at the transport layer, i.e., the total 
number of network packets successfully transmitted through the network and received 
error-free at the destination node. 

Several types of messages were sent over the course of the Seaweb 2004 
experiment. Examples of the kinds of messages were own vehicle positions, command 
and control messages, general network health monitoring, node-to-node ranging, and 
network routing. Regardless of type, each data packet sent through the Seaweb server is 
designated with a network packet sequence number and a timestamp. The sequence 
numbers range from 1 to 255, and then cycle back to 1. By tracking the sequence number 
along with the associated timestamp, we are able to count the number of packets 
successfully transmitted and received by the ship and by the undersea vehicle. Limiting 
our analysis to traffic between the undersea vehicle and the ship, the messaging success is 
compiled in Figure 22. 

Initially the Seaweb administrator exercised the Seaweb pilot network through a 
FreeWave radio link between the ship and the deployed racom buoy. All 7 pilot grid 
repeater nodes were found to be fully functional. The testing performed included data 
telemetry of 1-kilobyte test packets at information bit-rates of 300 and 800 bits/s. Testing 
also involved remote selection of transmit power levels, node-to-node acoustic ranging. 
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node-to-multinode ranging, and networked interrogation of modem diagnostics. As a 
result of those tests, the baseline data rate for Seaweb 2004 was increased from 300 bits/s 
to 800 bits/s, and the baseline transmit power level was set to 6 dB less than the 
maximum power available. Successful communications with these parameters at ranges 
exceeding 6 km provided confidence that the 3-km node spacing would reliably serve the 
needs of the exercise. The overall results support this conclusion as well. 
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Figure 22. The total amount of messages sent from the undersea vehicle and the ship 

as well as those received onboard the undersea vehicle and ship. One hundred and 
sixty messages were unsuccessfully received onboard the ship and fifty messages 
were not received onboard the undersea vehicle. Section C identifies the reasons 
for these dropped messages. 
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Figure 23. 


Figure 24. 


Transport Layer Messaging Success 


Undersea Vehicle to Ship 



Messaging success from undersea vehicle to ship also tended to increase 
on a daily basis. As the experiment progressed, sensitivity to the issues of 
proximity and aspect of the undersea vehicle relative to the cellular node 
increased messaging success. 


Transport Layer Messaging Success 
Ship to Undersea Vehicle 



Messaging success from ship to undersea vehicle increased over the 
course of the experiment. This is attributed to decreasing ambient noise levels 
within the environment, troubleshooting and rerouting of the network, and 
increased operator proficiency. 
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During the days of experimentation, the Seaweb administrator did not exercise the 
grid in a rigorous manner. As the goal of the experiment was bidirectional 
communications between the undersea vehicle and the ship and the communications 
protocol established that the surface vehicle would wait to receive a message prior to 
sending one, the operators were compelled to keep the network available to the undersea 
vehicle. Network packets were sent to various nodes within the grid only in response to 
an issue encountered with that node or one around it, or during time periods when the 
undersea vehicle was known to be operating elsewhere. 

Daily transport layer success rates to ship and undersea vehicle are compiled in 
Figures 23 and 24, respectively. The trend shows steadily improving performance over 
the course of the experiment, especially for communications to the undersea vehicle. 
Progressively increased messaging success to the undersea vehicle is attributable to the 
following factors. The established communications protocol favored the messaging from 
the ship to the undersea vehicle. The ship knew from which cell the undersea vehicle 
transmitted and used this information to return a response message prior to the undersea 
vehicle leaving that cellular area of the grid. As the undersea vehicle maneuvered within 
the domain of the grid, the ship was able to observe behavior and improve performance 
of the various nodes in the grid. These optimizations, of course, should have occurred 
prior to the experiment with end-to-end testing as had been planned. As well, the ambient 
noise within the operating environment decreased during the experiment, as supported by 
Figure 6. 

Not only did the testing and correcting by the Seaweb administrator increase 
messaging success to the undersea vehicle, it also increased messaging success from the 
undersea vehicle as well. After discovering the loss of Nodes 23 and 25, the ship was able 
to reroute network traffic around that area, thus significantly improving the overall 
performance of the grid. The undersea vehicle also did not exercise the grid uniformly. It 
tended to use the southernmost portion of the grid more than the northern portion. Due to 
the nonsystematic fashion in which nodes were selected as communication access points, 
it is difficult to determine the relative effectiveness of all network nodes. 
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B. LATENCY 


The automatically generated timestamps in the Seaweb server archive were used 
to calculate latency times. The latency times are divided into 3 analysis categories: ship 
to undersea vehicle, undersea vehicle to ship, and ship to fixed node. Latencies are then 
plotted as a function of range. Ranges are calculated by using the distance from the 
gateway buoy to the network node as addressed by the administrator or as used as a 
communications access point by the undersea vehicle. As expected, latency increased 
linearly with range. In order to support effective bidirectional communications, it is 
imperative that latency times, much larger than terrestrial counterpart systems, be kept to 
a minimum. Latency times will decrease with the planned implementation of automatic 
“best-route” routing algorithms in the future. 
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Figure 25. The ship to undersea vehicle latency is calculated using the timestamps 

entered into the database archives by the Seaweb servers. This is a latency that 
includes the handshaking process between all nodes in the route from source to 
destination. 
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Undersea Vehicle to Surface Ship Latency 


Figure 26. 


Figure 27. 
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The undersea vehicle to ship latency is calculated using the timestamps 
from the database. The range is determined by using the distance from the cellular 
node the undersea vehicle used to transmit the data packet to the ship and back. 
The distance from the undersea vehicle to the node is neglected. 

Message Latency from Surface Ship to Nodes 



Range (nm) 


Nodal latencies are calculated in the same fashion as those of the ship and 
undersea vehicle. These transmissions were always between fixed locations which 
explain is why they exhibit a more linear fit. 
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C. DROPPED MESSAGES 

A dropped message is defined as a message that was transmitted by a source node 
and not received by the intended destination node. Some of these dropped messages are 
the result of human interaction with the system, while most are due to various 
engineering issues associated with the present Seaweb system operating with a mobile 
node. The sequence number and specific timestamp enable us to track each network 
packet from source to destination. A sequence number that is not correctly received is 
analyzed and the dropped message is attributed to one of many causes based on the 
logged link diagnostics. 

In this analysis, transmissions are separated into those transmitted by the undersea 
vehicle and those transmitted from the ship. These data are compiled and charted in 
Figures 28 and 29, with a view of overall performance at the transport layer. The 
undersea vehicle sent considerably more network packets as a result of the established 
Seaweb 2004 session protocol. The following is a discussion of the categories of dropped 
messages identified during Seaweb 2004. 

Several messages were dropped because of link impairments. These categories 
include link unavailability (RTS timeout), low signal-to-noise ratio (SNR), and data 
failure problems. For this analysis, the low-SNR category captures most physical-layer 
degradations caused by the combination of low signal (i.e., poor propagation) and high 
noise. 

Request-to-Send timeouts occur when Node A initiates the link-layer handshaking 
procedure with Node B, but Node A does not receive a Clear-to-Send message. When 
this happens. Node A will continue to send 9-byte RTS packets up to a preset number of 
attempts programmed by the administrator. Upon time-out, the packet is dropped. 

Even when the RTS/CTS handshake is successful, low-SNR errors occur when 
the link budget is not adequate for error-free reception of the data packet. If Node B 
cannot demodulate the data packet correctly, it produces a low-SNR detection error and 
drops the network packet. 
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Transport Layer Error Modes for 
Undersea Vehicle to Ship Message Attempts 


Figure 28. 


Figure 29. 
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The 160 dropped messages not received successfully by the ship are 
attributed to the various factors listed in this chart. 


Tranport Layer Error Modes for 
Ship to Undersea Vehicle Message Attempts 
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The 50 dropped messages not received successfully by the undersea 
vehicle are attributed to the various factors listed in this chart. 
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Data Failure error messages cause packets to be dropped when Node B receives 
the data packet, assumes it was correctly transmitted, and upon demodulation realizes the 
data string is corrupt. Normally in the hand-shaking procedure Node B would send a 
Selective ARQ message to Node A upon receipt of the corrupt packet. If Node A does 
not receive the SRQ within the allotted time period, it does not resend the data packet, 
thus producing a dropped message. 

Hardware issues caused dropped messages when the racom buoy had to be 
rebooted and when no transmit (No XMT) errors occurred. If a network packet was in the 
process of being transmitted, the reboot would cause the packet to be dropped since it 
never made it from the ship to the racom gateway buoy and henceforth to the addressed 
node or undersea vehicle. 

Transmissions originating at the undersea vehicle were more prone to being 
dropped since the vehicle often did not have a good sense of where it was relative to the 
nodes in the grid. Physical limitations such as distance from the node used as the 
communications access point, vehicle aspect to the node, a bad link between other nodes 
within the grid that are being used to transmit through to the destination, and other sonars 
operating within the water-space around the network caused messages to be dropped. 
Because Seaweb is currently operated with man in-the-loop, operator error sometimes 
adversely influenced messaging success. 

Overall, most of the issues influencing Seaweb 2004 message delivery can be 
resolved by improving the engineering of the system with mechanisms such as link 
automatic rerouting and modem reboots. Others, such as operator error and other sensors 
operating within the same water-space, need continued testing and development. 
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VIII. FUTURE IMPROVEMENTS 


The 5 by 20 nautical mile Seaweb 2004 grid of 40 subsea nodes was the largest 
wide-area acoustic network ever to be demonstrated. As with any experimental 
implementation, there is room for improvement with equipment, hardware, and 
personnel. Recommendations follow. 

A. NAVIGATION POSSIBILITIES WITHIN THE SEAWEB GRID 

A significant lesson learned is the importance of the undersea vehicle awareness 
of its own position within the grid as a prerequisite for effective operation as a mobile 
node. This lesson has led to the dual use of the Seaweb fixed grid as an undersea 
constellation of reference points for GPS-like navigation. A series of 3 Seaweb 
engineering experiments in 2005 (May, July, December) are developing that navigation 
capability as a Seaweb function. Seaweb navigation and Seaweb communication are 
therefore becoming highly interdependent functions, especially so for future mobile 
connectivity requirements. [24, 25] 

B. MOBILE CONNECTIVITY 

Implementing mobile connectivity will enable seamless communications with 
undersea vehicles in the Seaweb domain. In order to achieve this, cellular addressing 
needs further development to support automated mobile connectivity. Seaweb diagnostics 
must be improved and further automated. Finally, a true ping command that would trace 
the outbound and inbound routes would aid in post-experiment exercise analysis. 

C. ROUTING 

Network routing and initialization was done manually during this experiment. 
Seaweb of tomorrow is an ad hoc network which will autonomously establish preliminary 
connections. A procedure is required for performing initialization and maintaining 
connectivity to all nodes within acoustic range. During the initialization process, the 
nodes would create their own neighbor tables to include the quality of the acoustic links 
between themselves and their neighbors. A master node would collect this information to 


51 



determine the best routing configuration. By utilizing an adaptive routing algorithm, an 
increase in robustness would allow the network to react to changing channel conditions 
without interruption in communications. Each time the network is used, the link 
parameters exercised along the route would be reported, thus allowing the master node to 
efficiently monitor network health [16, 18]. 

Neighbor Sense Multiple Access (NSMA) is a network layer process that 
passively monitors Seaweb traffic. After assessing the communications status of neighbor 
nodes, a node with a message to be transmitted avoids unnecessary collisions by delaying 
new dialog until the neighbor node is finished, or it transmits. This is an added measure 
for collision avoidance. NSMA was successfully demonstrated at sea in a February 2005 
Seaweb experiment [16]. 

In future experiments, routine testing of all routes within the network should take 
place on a daily basis. This would provide a baseline from which network reconstruction 
could be derived. Without daily verification of the network health, it is difficult to specify 
the time-frame in which a node stopped working and/or was trawled. 

D. RACOM BUOYS 

In order to implement Seaweb as a fixture for underwater communications, it is 
imperative that an improved design for racom buoy rugged handling be designed. Until 
then, waiting for calm seas is necessary for successful recovery. The radar reflector 
should be eliminated, a taller prow designed, flush GPS and Iridium antennas added, and 
an improved transducer cable developed. Racom buoy wet-end survivability must be 
addressed as well. Utilizing the military version of the FreeWave radio modems 
operating at 138 MHz and supporting up to 50-nautical-mile line-of-sight connectivity 
vice the shorter range 900-MHz commercial FreeWave modems would increase stable 
connectivity for communications. In addition, efforts are underway to produce an energy¬ 
harvesting, mooringless racom buoy capable of maintaining station or vectoring to a new 
station upon command. [3] 
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E. TELESONAR NODES 

Seaweb capability is migrating to new telesonar modem hardware compatible 
with A-sized air-deployable packaging and with submarine signal-ejector packaging 
enabling further versatility and military applicability. The Seaweb of tomorrow will 
operate in multiple acoustic bands and will incorporate electronically steered directional 
transducers for improved transmission security (TRANSEC), link budget, energy 
conservation, and multiple-access performance. The new modems will incorporate 
channel-adaptive modulation, spread-spectrum-modulated utility packets, power control, 
and coherent detection. 

F. SEAWEB ADMINISTRATORS, OPERATORS, AND USERS 

As with any system, it is imperative that there be enough personnel trained to 
operate and facilitate use so that the system can physically be manned in an intelligent 
and sophisticated manner. With the lack of personnel qualified to manipulate the system, 
the individuals that were trained to administer the server became fatigued. In order to 
exploit Seaweb capabilities more operators need to be trained and made available during 
testing periods. Since future testing will involve more manned platforms, it is all the more 
important to recruit and train new Seaweb personnel. 

It is also recommended that a shipboard sonobuoy receiver system be procured for 
independent real-time monitoring of Seaweb acoustic activity and ambient noise. 

G. FINANCIAL SUPPORT FOR FUTURE ASW CAPABILITIES 

The Seaweb underwater acoustic wide-area network shows great potential. It is 
consistent with the future proliferation of autonomous undersea sensors and vehicles. Not 
only does Seaweb show potential for communication and navigation of an undersea 
vehicle, but it could conceivably be incorporated as a rapidly deployable undersea 
wireless grid supporting communication and navigation (comm/nav) for a patrolling SSN 
operating at speed and depth. Seaweb demonstrated timely communications to and from 
the Seaweb 2004 undersea vehicle. In the current anti-submarine warfare (ASW) 
environment, Seaweb could act as the bridge between terrestrial communications and the 
underwater battlespace. It could potentially afford submarines the ability to communicate 
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in stride without surfacing. In order for this to come to fruition, the Navy needs to invest 
resources in the procurement and further development of Seaweb capabilities. Seaweb 
enables new concepts of operations involving autonomous distributed systems, and it 
integrates existing systems into that future architecture. 
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IX. CONCLUSIONS 


The Seaweb architecture anticipates the inevitable proliferation of future undersea 
sensors. Seaweb is a technology motivated by the need to network these distributed 
sensors and communicate with them through gateway nodes. It is a malleable architecture 
that can be matched to the characteristics of the particular ocean environmental 
conditions and mission at task. 

The Seaweb 2004 experiment demonstrated a 5 by 20 nautical mile grid, the 
largest undersea network to date. The network maintained a reliable 800 bits/s physical 
layer while demonstrating effective collision tolerance. As well, rerouting healed the 
network following severe impact by trawling within the first few days of testing. During 
the experiment less than 25% of the overall telesonar node battery capacity was 
consumed. The undersea vehicle, while a disadvantaged receiver, maintained 
bidirectional communications through the low-power distributed grid. 

The overall performance of Seaweb 2004 was impacted by the use of an 
azimuthally sensitive undersea vehicle, no opportunities for end-to-end testing prior to 
commencing the exercise, adverse weather conditions, trawling impact, and limited 
operator availability. Even with the very short schedule and many challenges, Seaweb 
2004 has successfully demonstrated an effective network architecture for undersea 
vehicle communications at speed and depth. Seaweb is scaleable, and it is consistent with 
future operations involving deployable autonomous sensors and unmanned undersea 
vehicles as force multipliers. The current operational environment requires that offboard 
sensors, fixed and mobile, be developed and ready for fleet use within the next few years. 
Seaweb stands as the most developed underwater acoustic communications network and 
is a new ASW capability deserving Navy investment. 
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